1. Field of the Invention
The present invention relates to the field of operating systems, and, more specifically, to incorporating into an existing operating system, installation code to install previously unsupported platform specific kernels and device specific drivers.
2 . Background of the Invention
When a user flips a computer's ON switch the computer begins a process known as the system boot. The system boot process on most machines consists of the following basic steps. First the system firmware in the programmable read-only memory ("PROM") runs a power-on self-test ("POST") to ensure that all hardware components are functioning properly. If the POST test completes successfully then a boot block is read from a permanent memory area (e.g., a disk drive) on the computer. When booting to install a new system, the boot block typically instructs the computer to search a CD-ROM drive or a disk drive for an operating system kernel. The operating system kernel is the core of the operating system. The kernel contains the most essential operating system services, such as task schedulers and interrupt handlers. When the operating system kernel files are found they are read into the computer's random access memory ("RAM") and control is transferred to the kernel. The operating system then takes on the more complicated tasks that the boot block code cannot manage. For example, the operating system mounts the necessary filesystems and loads input/output ("I/O") routines. One of the masons for loading the operating system from a CD-ROM drive or disk drive and not pre-installing the operating system is to allow users a choice of which operating system to load and use.
One of the more important functions that the operating system kernel performs during system boot is installation of device specific drivers. A driver is a program that serves as an interface between two programs or between a program and a hardware component. For example, to ensure that a network interface card will work with a particular network software package, drivers are used. To install means to set up and prepare for operation. Therefore, to install device drivers means to set up and prepare the device drivers to work with the computer and its device. Installing device specific drivers to operate the hardware components of a computer has been customary since the advent of personal computers and workstations. Device specific drivers are not typically pre-installed because computers are general purpose machines designed and developed to work with a myriad of different hardware components to accomplish thousands of different functions. Due to limitations in memory capacity it is impractical to load each and every device driver that could possibly be invoked by the system. Instead, the computer determines which hardware components are actually connected to the system, often through a "dialog" with a systems administrator, and then loads the device drivers for those hardware components.
Typically, the responsibility to develop device specific drivers falls to the manufacturer of the device. Responsibility to develop platform specific kernels fails primarily to operating system developers. Finally, responsibility to develop code to install device specific drivers and platform specific kernels falls to developers of operating systems. Since the resources of any given operating system developer are not limitless, they cannot develop kernels to support each and every platform on the market. They also cannot develop installation code to install all possible device drivers. Therefore, any given version (called a "base version") of an operating system only includes installation code to install a limited number of kernels and drivers.
A problem arises when original equipment manufacturers ("OEMs") develop new computer systems which are not supported by the base version of the operating system. A user of the new computer system, running the base version of the operating system, will not be able to access unsupported hardware components because the operating system never installs a platform specific kernel and device specific drivers which can recognize and handle application program calls to the new hardware. Being unable to communicate with some of the components of your system can cause serious problems. For example, if the unsupported hardware component is the user's current keyboard then the user will be unable to enter data into the system.
In the past, operating system developers and OEMs have tried to solve this problem in a number of different ways. For example, some operating system developers transfer to each OEM a copy of the source code for the base version of the operating system. The OEM then modifies the source code to create a new kernel with some new device drivers which together accept requests from application programs and translate those requests into a language which the (previously) unsupported hardware component can understand. The OEM then transfers the modified operating system onto a compact disc and offers the new CD for sale. One of the problems with this approach is that a user of the operating system needs to purchase separate CDs from separate sources in order to have copies of the operating system which execute on the different hardware systems available in the market.
In addition to having the problem of separate CDs, a user, who is not generally interested in the procedural and administrative details of installing additional kernels, must nonetheless struggle with the various installation procedures from different OEMs. Thus a need exists to supply a consistent installation procedure across various kernels.